The assembler supports designation of arbitrary sections with the .section and .zerofill directives (descriptions apear below). Only those sections specified by a directive in the assembly file appear in the resulting object file (including implicit .text directives--see " Built-in Directives for Designating the Current Section "). Sections appear in the object file in the order their directives first appear in the assembly file. When object files are linked by the link editor, the output objects have their sections in the order the sections first appear in the object files that are linked. See the ld (1) Mac OS X man page for more details.
Associated with each section in each segment is an implicit location counter which begins at zero and is incremented by 1 for each byte assembled into the section. There is no way to explicitly reference a particular location counter, but the directives described here can be used to "activate" the location counter for a section, making it the current location counter. As a result, the assembler begins assembling into the section associated with that location counter.
Note: If the -n command line option isn't used, the (__TEXT,__text) section is used by default at the beginning of each file being assembled, just as if each file began with the .text directive.
.section
segname
,
sectname
[[[
,
type
]
,
attribute
]
,
sizeof_stub
]
The .section directive causes the assembler to begin assembling into the section given by segname and sectname . A section created with this directive contains initialized data or instructions and is referred to as a content section. type and attribute may be specified as described below under " Section Types and Attributes ." If type is symbol_stubs, then the sizeof_stub field must be given as the size in bytes of the symbol stubs contained in the section.
.zerofill
segname
,
sectname
[
,
symbolname
,
size
[
,
align_expression
]]
The .zerofill directive causes symbolname to be created as uninitialized data in the section given by segname and sectname , with a size in bytes given by size . A power of 2 between 0 and 15 may be given for align_expression to indicate what alignment should be forced on symbolname , which will then be placed on the next expression boundary having the given alignment. See the description of the .align built-in directive for more information.
A content section has a type, which informs the link editor about special processing needed for the items in that section. The most common form of special processing is for sections containing literals (strings, constants, and so on) where only one copy of the literal is needed in the output file and the same literal can be used by all references in the input files.
A section's attributes record supplemental information about the section that the link editor may use in processing that section. For example, the reloc_at_launch attribute indicates that a section should be relocated immediately when a program is launched.
A section's type and attribute are recorded in a Mach-O file as the flags field in the section header, using constants defined in the header file mach-o/loader.h . The following paragraphs describe the various types and attributes by the names used to identify them in a .section directive. The name of the related constant is also given in parentheses following the identifier.
A regular section may contain any kind of data and gets no special processing from the link editor. This is the default section type. Examples of regular sections include program instructions or initialized data.
A cstring_literals section contains null-terminated literal C language character strings. The link editor places only one copy of each literal into the output file's section and relocates references to different copies of the same literal to the one copy in the output file. There can be no relocation entries for a section of this type, and all references to literals in this section must be inside the address range for the specific literal being referenced. The last byte in a section of this type must be a null byte, and the strings can't contain null bytes in their bodies. An example of a cstring_literals section is one for the literal strings that appear in the body of an ANSI C function where the compiler chooses to make such strings read-only.
A 4byte_literals section contains 4-byte literal constants. The link editor places only one copy of each literal into the output file's section and relocates references to different copies of the same literal to the one copy in the output file. There can be no relocation entries for a section of this type, and all references to literals in this section must be inside the address range for the specific literal being referenced. An example of a 4byte_literals section is one in which single-precision floating-point constants are stored for a RISC machine (these would normally be stored as immediates in CISC machine code).
An 8byte_literals section contains 8-byte literal constants. The link editor places only one copy of each literal into the output file's section and relocates references to different copies of the same literal to the one copy in the output file. There can be no relocation entries for a section of this type, and all references to literals in this section must be inside the address range for the specific literal being referenced. An example of a 8byte_literals section is one in which double-precision floating-point constants are stored for a RISC machine (these would normally be stored as immediates in CISC machine code).
A literal_pointers section contains 4-byte pointers to literals in a literal section. The link editor places only one copy of a pointer into the output file's section for each pointer to a literal with the same contents. The link editor also relocates references to each literal pointer to the one copy in the output file. There must be exactly one relocation entry for each literal pointer in this section, and all references to literals in this section must be inside the address range for the specific literal being referenced. The relocation entries can be external relocation entries referring to undefined symbols if those symbols identify literals in another object file. An example of a literal_pointers section is one containing selector references generated by the Objective C compiler.
A symbol_stubs section contains symbol stubs, which are sequences of machine instructions (all the same size) used for lazily binding undefined function calls at run time. If a call to an undefined function is made, the compiler outputs a call to a symbol stub instead, and tags the stub with an indirect symbol that indicates what symbol the stub is for. On transfer to a symbol stub, a program executes instructions that eventually reach the code for the indirect symbol associated with that stub. Here's a sample of assemly code based on a function func() containing only a call to the undefined function foo() :
.text
.align 4, 0x90
_func:
call _foo_stub
ret
.symbol_stub #
_foo_stub: #
.indirect_symbol _foo #
ljmp _foo_lazy_ptr # the symbol stub
_foo_stub_1: #
pushl $_foo_lazy_ptr #
jmp dyld_stub_binding_helper #
.lazy_symbol_pointer #
_foo_lazy_ptr: # the symbol pointer
.indirect_symbol _foo #
.long _foo_stub_1 # to be replaced by _foo's address
In the assembly code, _func calls _foo_stub , which is responsible for finding the definition of the function foo() . _foo_stub jumps to the contents of _foo_lazy_ptr , initially causing the code at _foo_stub_1 to be executed. This value is initially the address for _foo_stub1 , which calls the dyld_stub_binding_helper() function to overwrite the contents of _foo_lazy_ptr with the address of the real function, _foo . This way, jumps through _foo_lazy_ptr will immediately execute foo() 's code.
The indirect symbol entries for _foo provide information to the static and dynamic linkers for binding the symbol stub. Each symbol stub and lazy pointer entry must have exactly one such indirect symbol, associated with the first address in the stub or pointer entry. See the description of the .indirect_symbol directive for more information.
The static link editor places only one copy of each stub into the output file's section for a particular indirect symbol, and relocates all references to the stubs with the same indirect symbol to the stub in the output file. Further, the static link editor eliminates a stub if a definition of the indirect symbol for that stub is present in the output file and that output file isn't a dynamically linked shared library file. The stub can refer only to itself, one lazy symbol pointer (referring to the same indirect symbol as the stub), and the dyld_stub_binding_helper() function. No global symbols can be defined in this type of section.
A lazy_symbol_pointers section contains 4-byte symbol pointers that will eventually contain the value of the indirect symbol associated with the pointer. These pointers are used by symbol stubs to lazily bind undefined function calls at run time. A lazy symbol pointer initially contains an address in the symbol stub of instructions that cause the symbol pointer to be bound to the function definition (in the example above, the lazy pointer _foo_lazy_ptr initially contains the address for _foo_stub_1 but gets overwritten with the address for _foo ). The dynamic link editor binds the indirect symbol associated with the lazy symbol pointer by overwriting it with the value of the symbol.
The static link editor only places a copy of a lazy pointer in the output file if the corresponding symbol stub is in the output file. Only the corresponding symbol stub can make a reference to a lazy symbol pointer, and no global symbols can be defined in this type of section. There must be one indirect symbol assocated with each lazy symbol pointer. An example of a lazy_symbol_pointers section is one in which the compiler has generated calls to undefined functions, each of which can be bound lazily at the time of the first call to the function.
A non_lazy_symbol_pointers section contains 4-byte symbol pointers that will contain the value of the indirect symbol associated with a pointer that may be set at any time before any code makes a reference to it. These pointers are used by the code to reference undefined symbols. Initially these pointers have no interesting value, but will get overwritten by the dynamic link editor with the value of the symbol for the associated indirect symbol before any code can make a reference to it.
The static link editor places only one copy of each non-lazy pointer for its indirect symbol into the output file and relocates all references to the pointer with the same indirect symbol to the pointer in the output file. The static link editor futher can fill in the pointer with the value of the symbol if a definition of the indirect symbol for that pointer is present in the output file. No global symbols can be defined in this type of section. There must be one indirect symbol assocated with each non-lazy symbol pointer. An example of a non_lazy_symbol_pointers section is one in which the compiler has generated code to indirectly reference undefined symbols to be bound at run time--this preserves the sharing of the machine instructions by allowing the dynamic link editor to update references without writing on the instructions.
Here's an example of assembly code referencing an element in the undefined structure. The corresponding 'C' code would be:
struct s {
int member1, member2;
};
extern struct s bar;
int func()
{
return(bar.member2);
}
The i386 assembly code might look like this:
.text
.align 4, 0x90
.globl _func
_func:
movl _bar_non_lazy_ptr,%eax
movl 4(%eax),%eax
ret
.non_lazy_symbol_pointer
_bar_non_lazy_ptr:
.indirect_symbol _bar
.long 0
A mod_init_funcs section contains 4-byte pointers to functions that are to be called just after the module containing the pointer is bound into the program by the dynamic link editor. The static link editor does no special processing for this section type except for disallowing section ordering. This is done to maintain the order the functions will be called (which is the order their pointers appear in the original module). There must be exactly one relocation entry for each pointer in this section. An example of a mod_init_funcs section is one in which the compiler has generated code to call C++ constructors for modules that get dynamicly bound at run time.
The pure_instructions attribute means that this section contains nothing but machine instructions. This attribute would be used for the (__TEXT,__text) section of Mac OS X compilers and sections which have a section type of symbol_stubs.
This attribute is set by the assembler whenever it assembles a machine instruction in a section. There is no directive associated with it, since you cannot set it yourself. It is used by the dynamic link editor together with the S_ATTR_EXT_RELOC and S_ATTR_LOC_RELOC, set by the static link editor, to know it must flush the cache and other processor related functions when it relocates instructions by writing on them.